In a system wherein a workstation connected to a private network using Internet Protocol (IP) wants to communicate with a peer device connected to a public network also using IP protocol, a network address translation (NAT) or a network port address translation (NPAT) when several ports are used, is implemented at the network boundary to change the IP address and possibly the port value of each data packet.
But some applications are not compatible with the NAT function. Thus, in secure VPN using IPsec for example, the Security Association (SA), which is the method for creating a secure link, is established between the two end-points that will need a secure IPsec tunnel between them. These end points are not necessarily on the same network and devices in between such as firewalls or gateways use the NAT on the local IP address in order to provide routability. Once “NATed” , the SA or IPsec packets may not be recognized by the other end since the packets may contain the original IP address, may include a signature including the original IP address_or may not have the a valid port number.
Other protocols such as FTP, IRC, SNMP, LDAP (Internet Engineering Task Force protocols) or H.323 (International Telecommunication Union protocol) are also totally or partially incompatible with the NAT mechanism insofar as the source IP address of the header is different from the address transported with the data payload. That is the case with the protocol H.323 used in transporting voice over IP (VoIP) and where a proxy function is often required in gateways.
NAT was originally developed as a short-term measure to combat Ipv4 address exhaustion. However, widespread implementation and lengthy migration to Ipv6 have made it impossible for IPsec vendors to ignore NAT. Cisco, CheckPoint, F-Secure, Microsoft, and SSH Communications are among those vendors working to enable IPsec NAT traversal.
The Internet Engineering Task Force (IETF) has been working protocol by protocol to find solutions. But these are generally difficult to implement and do not solve all the cases. NAT traversal standard is one IETF example but a few problems still remain.
When the NAT or NPAT device in the middle is not under control, no special mechanism can be implemented to allow pass-through for the various protocols having problems with NAT/NPAT. Only encapsulation of all the related flow over a dedicated encapsulation mechanism (generally based on UDP) between end peers may be used. This adds complexity and overhead and implies generally a change on the application or system.